That's not what we want though, we don't want to use my fork indefinitely. Upstream should work for us now.

I tried it with local zola and got an error because of the permalink. I'll try with the latest version now.

In general, checking out the recursive submodules and building Zola is... interesting. I would perhaps point people to https://www.getzola.org/documentation/getting-started/installation/ or even better to https://github.com/getzola/zola/releases/tag/v0.21.0, it IMO seems easier than building a 500+ dependency binary in release mode with LTO and CGU=1 and fetching tens of submodules.

IIRC @Manishearth is against telling people to install random binaries we don't control.

Hmm, while I get that sentiment, I'm not sure if it's that much better if we tell them to checkout 25 submodules and build 500+ Rust dependencies, which we also don't control. We kind of gave up "control" when it was decided to switch from in-tree Rust rendering to Zola.

Right, but building from a commit hash is more deterministic than downloading binaries from a URL.

Can't argue with that, although we could add some helper script that verifies the binary SHA, that shouldn't be that difficult.

I just see it as a contributor roadblock currently, because building the Zola binary is really resource intensive, both network and CPU wise, and takes 5+ minutes even on a relatively powerful laptop. Of course it only has to be done "once in a while", but people don't write blog posts that often, so it is (IMO a big) annoyance. So from my POV it would be worth it to simplify this as much as possible.

In the extreme case, we could build the binaries on the blog's CI and let people download it from there, but that's IMO too complicated.

I definitely agree with the fact that it's annoying. Not sure what the best solution is.